[小ネタ] VPCの同一サブネット内通信でNetwork ACLが評価されるか確認してみた

しばたです。

現在Transit Gateway環境でのNetwork ACLの動作について調べているのですが、その際に「そもそも同一サブネット内での通信ではNetwork ACLって評価されないよな？」という点が気になったので実際に確認してみました。

ちょっとググればすぐ裏どりできる想定だったのですが、意外と苦労したので本記事で記録を残しておきます。

AWSのドキュメント

AWSのドキュメントでは下図の様にNetwork ACLは2つのサブネットにまたがる通信を行う際のルーティングの前後において評価されるとされています。

• ネットワーク ACL を使用してサブネットへのトラフィックを制御する

この図だけだと「同一サブネット内の通信はどうなの？」という疑問を解消できませんが、ドキュメントを注意深く読むと

• ネットワーク ACL ルールは、トラフィックがサブネット内でルーティングされるときではなく、サブネットに出入りするときに評価されます。

(日本語)

• We evaluate the network ACL rules when traffic enters and leaves the subnet, not as it is routed within a subnet.

(英語)

の一文があり、同一サブネット内の通信では評価されないことがわかります。

これで裏どりはできましたが、せっかくなので実際に動作確認もしてみます。
(というより、実際には上記の文言を見つけるのに予想外に苦労してしまい先に検証をはじめていたのが実情です...)

検証環境

今回は私の検証用AWSアカウントの東京リージョンにVPCを一つ用意して動作確認していきます。
VPC内に2つのPrivate Subnet(test-subnet-01, test-subnet-02)とNetwork ACL(test-nacl-01, test-nacl-02)を用意しておきます。

2つのNetwork ACLは全てのIPv4通信を通す設定にしています。

(test-nacl-02も同様。IPv6については使用しないため未定義)

1. 同一サブネット内での通信

はじめにtest-subnet-01に2つのAmazon Linux 2023 EC2(EC2-01, EC2-02)を用意し、互いに全ての通信を許可するセキュリティグループをアタッチしておきました。

各EC2のPrivate IPは以下の通りです。

• EC2-01 : 10.0.100.67
• EC2-02 : 10.0.100.14

この状態で、まずはVPC Reachability Analyzerを使ってTCP通信を分析してみました。
結果は下図の通りです。

確かにEC2-01のENIからの通信はNetwork ACLを介すること無くEC2-02のENIへ到達するのが見て取れます。
実際にtest-nacl-01の設定を変え全てのICMP通信を拒否する様にしてみましたが、

Network ACLは評価されないためEC2-01からEC2-02へのPingはエラー無く成功します。

# EC2-01 : 10.0.100.67 から EC2-02 : 10.0.100.14 へPingは成功する
$ ping -c 4 10.0.100.14
PING 10.0.100.14 (10.0.100.14) 56(84) bytes of data.
64 bytes from 10.0.100.14: icmp_seq=1 ttl=127 time=0.398 ms
64 bytes from 10.0.100.14: icmp_seq=2 ttl=127 time=0.479 ms
64 bytes from 10.0.100.14: icmp_seq=3 ttl=127 time=0.460 ms
64 bytes from 10.0.100.14: icmp_seq=4 ttl=127 time=0.472 ms

--- 10.0.100.14 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3095ms
rtt min/avg/max/mdev = 0.398/0.452/0.479/0.032 ms

2. 別サブネットに対する通信

一応別サブネットにAmazon Linux 2023 EC2(EC2-03)を用意し、この場合の通信も検証しておきます。

各EC2のPrivate IPは以下の通りです。

• EC2-01 : 10.0.100.67 (変更なし)
• EC2-03 : 10.0.200.63

こちらに対してVPC Reachability Analyzerを使ってTCP通信を分析した結果は下図の通りです。

今度はtest-nacl-01のアウトバウンド通信、test-nacl-02のインバウンド通信がそれぞれ評価されていることが分かります。
(※戻りパケットはtest-nacl-02のアウトバウンド通信、test-nacl-01のインバウンド通信が評価される)

Pingによる疎通確認もNetwork ACLの設定変更の影響を受け、各Network ACLで拒否の設定を入れた場合は意図通り疎通不能になります。

# Network ACL設定が評価され疎通不能に。Netowork ACLはステートレスな点に注意
$ ping -c 4 10.0.200.63
PING 10.0.200.63 (10.0.200.63) 56(84) bytes of data.

--- 10.0.200.63 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3156ms

Netowork ACLはステートレスなため戻りパケットの評価にもご注意ください。

最後に

簡単ですが以上となります。

極めて基本的な内容ですが改めて確認するのは大事だなと感じました。
あとVPC Reachability Analyzerの便利さを再確認できたのが非常に良かったです。